storage: report actual disk usage per VM and image - #21

Follow-up to the accounting change, from two adversarial review passes.

Semantics. `exclusive` was `usedbydataset + usedbysnapshots`, but
snapshot-only space is by definition outside `referenced`, so both
image rows shipped reporting more occupancy than they reference. It is
now `usedbydataset`, a subset of `referenced` by ZFS's own definition,
and the contract says plainly that this is occupancy and not what a
destroy frees. The regression test now runs against the four rows a
live pool produces rather than a fixture that zeroed the field which
broke the invariant.

Pool compression counted empty refreservation as perfectly compressed
data, understating the ratio by 5%. `PoolUsage` gains `reserved`, the
ratio divides by the occupied remainder, and the CLI prints the
reservation as its own row so the volume rows visibly sum to the pool
line.

Read-only queries. dm-thin `usage()` no longer activates the pool, so
`ember vm list` cannot load a pool table, attach loop devices, and run
`thin_check` as a side effect of listing VMs. `try_usage` moved to
`src/backend.rs`, breaking a `cli::vm` <-> `cli::storage` import cycle,
and goes through a new fallible `try_create_storage` so a config naming
an unimplemented backend no longer panics the three commands you would
run to diagnose it.

Labelling. `RATIO` is `COMPRESSION`, `Ratio:` is `Compression:`, the
accessors are `compression_ratio()`, and `ember info` says `Capacity:`
rather than a second row called `Pool`.

Tests. All integration tests are `#[ignore]`d to match the rest of
`tests/`, since the runner passes `--ignored` and `TestEnv` needs root.
Fork creation was missing `--no-start` against a kernel that cannot
boot. The unmeasurable-storage test is Linux-only, because the APFS
backend reads neither field it clobbers. Adds the unit tests the spec
asked for: derived quantities and their zero guards, metadata block
scaling, and the thin-id join.

Retargets the docs, README, and `tests/macos_storage.rs` that still
referenced `ember debug storage-efficiency`.

The APFS usage model rested on st_blocks counting only the blocks a
file does not share with a clone. It does not. st_blocks counts the
blocks a file maps, so a fresh clone reports its origin's full figure
while costing nothing, and summing it over an install of one image and
fifteen clones overstates real occupancy by more than 5x.

Replace it with a physical extent scan. fcntl(F_LOG2PHYS_EXT) gives
the byte ranges a file maps, so sweeping every .img in the tree at once
yields exclusive, shared and a true pool figure. That restores all four
columns on macOS rather than blanking them, and it keeps the invariant
exclusive <= referenced true by construction.

Also record why the trait batches: on APFS a volume's exclusive figure
is only defined relative to every other volume that might share its
blocks, so a per-volume call could not express the answer at all.

Correct the same claim where it is repeated in MACOS-SPEC.md, and flag
it as unverified for reflinks in BTRFS-SPEC.md.

The APFS backend reported st_blocks as the exclusive figure. st_blocks
counts the blocks a file maps, not the ones it owns, so a fresh clone
reported its origin's full figure while costing nothing. A pure fork
that consumed 13 MiB was reported as 285 MiB, eight of them as 2283 MiB
against 10 MiB real, and pool.allocated grew every time a free clone was
made, which also made capacity (allocated + available) drift upward on a
volume that had not changed size.

Read physical extents instead. fcntl(F_LOG2PHYS_EXT) gives the byte
ranges a file maps and SEEK_DATA skips holes, so sweeping every .img in
the installation at once splits the tree into what each volume holds
alone and what the whole set costs. Measured against a tree of one
image, two VMs and three forks: 577638400 bytes reported against
578457600 actually freed by deleting it, an error of 0.14% where the old
figure was 2.64x over. The scan takes about 30 ms.

The sweep runs over the whole tree even when the caller passes one
record. Exclusivity is not a property a volume has on its own, so a scan
narrowed to the requested records would call every volume fully
exclusive.

All four columns now carry real numbers on macOS, and
exclusive <= referenced holds by construction rather than by arithmetic,
since the exclusive bytes are a subset of the file's own extents.

The sweep is pure interval logic and is unit tested without APFS
underneath. fork_shares_blocks_with_origin stops skipping on macOS,
where it had been returning early on a null referenced, leaving the one
assertion aimed at sharing unrun on the backend whose sharing was
broken.

`default-members = ["."]` means a bare `cargo test` covers only the
root package. CI ran 30 of 321 unit tests, so every test in ember-core
and in the platform backend was green by omission, including the
thin_ls and `zfs list` parsing tests this branch added and the spec
lists as its no-root coverage.

`--workspace` is not the fix. It selects the other platform's backend
too, and that backend does not build here: ember-macos needs
`clonefile` on Linux, and on macOS ember-linux's image tests want
`mkfs.ext4`. Naming the packages per platform is what actually works,
matching how `build` already branches on UNAME.

`check` and `clippy` get the same selection, so test-module code is
compiled and linted too. That immediately caught an
`items_after_test_module` failure in this branch's own accounting
tests, now moved to the end of the file.

`build` and `release` stay as they are: they build the root package,
which pulls the platform crate and ember-core in as dependencies, so
naming them would compile nothing new.

CI calls `make test` rather than `cargo test`, so the lint, check, and
test entry points stay consistent.